Software systems, such as enterprise resource planning (ERP) and automated planning system (APS), typically execute numerous tasks daily. For example, ERP and ARP can facilitate the planning and performance of various activities, such as finance, sales, inventory management, purchasing, production, forecasting, supply network planning, etc., and the tasks are executed to complete the planning and/or performance of these activities. These tasks are typically executed in application servers. Successful completion of these tasks typically depend on various aspects, such as completion of prerequisite tasks, availability of prerequisite master data and/or transaction data, etc. However, the execution of these tasks can fail due to various reasons, and can seriously affect the performances of the aforementioned activities, and the performance of the system that executes these tasks can be seriously degraded as a result (e.g., the system can be become underutilized as a result of failed execution of the tasks). Conventionally, the resolution of failed tasks includes diagnosis for root cause of failure, and search for one or more configurations for the software system (e.g., providing one or more arguments to a software function, and/or execution of one or more additional steps) based on the diagnosis.
There are several technical problems with the conventional method of resolving failed tasks. First, the diagnosis and search of configurations to resolve a failed task can take a lot of time, which can severely affect the performance of time-critical tasks (and the system that executes these tasks). This is especially true when there are a large number of potential causes for the failure, and/or there are a large number of potential configurations to resolve the failure. Second, in a case where there is only limited time and/or resource provided to resolve the failure, there is a need to focus on a smaller set of potential resolutions, but that typically requires lengthy diagnosis.